Міністерство освіти і науки України
НУ »Львівська політехніка»
Звіт
З дисципліни: Основи командної розробки
Розробив:
Група ПІм-41з
Перевірив:
Климаш Т.С.
м. Хмельницький
2012
Тема: Архітектура проекту у Visual Studio.
Мета: розробити архітектуру проекту у Visual Studio.
Коли проектується архітектура додатка, все красиво, логічно і відповідає кращим світовим практикам. Але в процесі роботи, стикаючись з обмеженнями пропонованими архітектурою, ми часто думаємо: «Ось тут трошки порушу, адже це заощадить мені годину часу розробки. Ну а потім, як буде час, поправлю ». Але, чомусь, цей час так ніколи і не настає. На мій погляд, єдиним способом змусити себе, як програміста, слідувати розробленій архітектурі, це навчити середовище розробки всі відхилення і милиці показувати як помилки компіляції. У цьому випадку, якщо код поганий, він відразу буде виправлений, ну а якщо архітектура застаріла, то буде виправлена вона. Тобто в сховище коду завжди буде код відповідної запланованої архітектурі.
Пара слів, про те, що буде підкатом:
Невелика преамбула.
Відновлення архітектури за наявним проектом.
Налаштування Visual Studio і TFS для автоматичного контролю архітектури.
Підготовка демонстраційного проекту Для демонстрації роботи з Layer Diagram, візьмемо проект, трохи ближчий до реальності. Нехай буде шар доступу до даних (Entity Framework) і, власне, шар клієнтських додатків в якому також буде шарувата структура (MVVM). У клієнтському рівні модель буде братися з першого шару, а от шари View і ViewModel будуть розмазані по декільком зборках. Ось так, ці чотири проекти виглядають після створення:
/
Рис.1
Можна змінити Namespace за замовчуванням для створюваних зборок. У цьому прикладі, для 3-х клієнтських зборок заменяєм Default Namespace:
/
Рис.2
Додаємо в проект DAL базу даних і Entity Model. У клієнтських проектах створюємо папки View і ViewModel. Додаємо в них тестові компоненти й класи:
Рис.3
Додавши посилання між проектами, звернення між створеними компонентами і класами, можна отримати граф залежностей приблизно такого вигляду:
/
Рис.4
Якщо розбиття на шари, йде на рівні зборок, то у зв'язку із забороною на циклічні посилання між збірками (інакше не можна визначити порядок побудови), можлива тільки проблема «звернення через шар». Якщо ж у проекті, як в даному випадку, шари розмазані по декільком зборках, причому в рамках однієї збірки є представники різних верств, перетягування проектів / файлів з Solution Explorer-а в Layer Diagram виявляється не ефективним. І тут на допомогу приходить Architecture Explorer, який викликається з головного меню: Architecture -> Windows -> Architecture Explorer. Відразу після відкриття він матиме вигляд:
/
Рис.5
Відновлення діаграми шарів з артефактів рішення Додаємо в рішення модельний проект, вже в нього додаємо Layer Diagram:
/
Рис.6
Тут ми можемо перетяуть з Toolbox-а шари, намалювати залежності, потім довго і наполегливо в ці шари переносити класи з клієнтських проектів. І все це тільки для того, щоб вже на наступний день, коли розробник додасть новий клас, про який ми не знаємо, і до шарів він не прив'язаний, а отже перевірка перестане працювати. Щоб цього уникнути, нам і придасться Architecture Explorer.
/
Рис.7
Зверніть увагу, що всі класи ViewModel опинилися в одному просторі імен (ну нехай в реальному проекті вони будуть в 3-5), і нам тепер можна в діаграму шарів додавати не класи, а цілком простору імен. Виділяємо їх і, не створюючи ніяких шарів, перетягуємо на нашу Layer Diagram:/
Рис.8
До речі, можемо скористатися і функціоналом перетягування проектів з Solution Explorer-а. З Shift-ом виділяємо в ньому ClientApp1, ClientApp2 і Base.Library, хапаємо лівою кнопкою миші і перетягуємо на вільне місце в Layer Diagram:
/
Рис.9
Перейменовуємо новий шар в Presentation, виділяємо два шари (View і View Model) і перетягуємо їх в шар Presentation:
/
Рис.10
Практично все готово, бракує тільки зв'язків. Для того, щоб їх згенерувати, досить викликати контекстне меню на Layer Diagram-е і ви...